1. Field of the Invention
The present invention relates to the field of queue management during data processing and, more particularly, to a solution for modifying a queue manager to support smart aliasing which permits extensible software to execute against queued data without application modifications.
2. Description of the Related Art
Just as computers have become more and more prevalent in everyday life, networks of linked computers have become important in distributing information amongst computer users. Through such networks, computer users can share information creating a virtual publishing medium which has become a viable alternative for the print medium.
A network of computers can be any number of computers that are able to exchange information with one another. The computers may be arranged in any configuration and may be located in the same room or in different countries, so long as there is some way to connect them together (for example, by telephone lines or other communication systems) so they can exchange information. Just as computers may be connected together to make up a network, networks may also be connected together through tools known as bridges and gateways. These tools allow a computer in one network to exchange information with a computer in another network.
In order to account for the fact that different computers connected to such a network may operate using different protocols and/or data formats, and also that different computers may be located in different time zones, asynchronous messaging and queuing software products have been developed.
Message queuing and commercially available message queuing products are described in “Messaging and Queuing Using the MQI”, B. Blakeley, H. Harris & R. Lewis, McGraw-Hill, 1994, and in the following publications which are available from IBM Corporation: “An Introduction to Messaging and Queuing” (IBM Document number GC33-0805-00) and “MQSeries—Message Queue Interface Technical Reference” (IBM Document number SC33-0850-01). IBM and MQSeries are trademarks of IBM Corporation. IBM's MQSeries messaging software products (now called Websphere MQ, “Websphere” is a trademark of IBM Corporation) provide transactional messaging support, synchronizing messages within logical units of work in accordance with a messaging protocol which gives assured once and once-only message delivery even in the event of system or communications failures. Websphere MQ products provide assured delivery by not finally deleting a message from storage on a sender system until it is confirmed as safely stored by a receiver system, and by use of sophisticated recovery facilities. Prior to commitment of transfer of the message upon confirmation of successful storage, both the deletion of the message from storage at the sender system and insertion into storage at the receiver system are kept “in doubt” and can be backed out atomically in the event of a failure. This message transmission protocol and the associated transactional concepts and recovery facilities are described in international patent application WO 95/10805 and U.S. Pat. No. 5,465,328, which are incorporated herein by reference.
In such a messaging and queuing system, the computer system that receives information over the network stores such received information in the form of messages in a queue. The computer system need not be operable when the messages are received over the network (e.g., the computer may be turned off if it is the middle of the night in the local time zone). The messages are simply stored in the queue for later retrieval at a time when the receiving computer system makes a request to retrieve a message from the queue. The receiving computer processor requests a specific message from the queue and this message is de-queued and provided to the receiving computer processor for processing thereby.
FIG. 1 (Prior Art) shows a conventional a simplistic queuing system 100. In system 100, application 105 can exchange digital information with remotely executing application 125 over network 115. Each application 105, 125 can have an associated queue manager 110, 120.
More specifically, an application 105 (running on a first machine) can identity a message to send to an application 125 (running on a second machine). Initially, the application 105 can send the message to a queue manager 110, which can also be running on the first machine. The queue manager 110 can then send the message over the network 115 to a queue manager 120 running on the second machine.
When utilizing HTTP based PUT and GET commands, the message transfer of system 100 can proceed as follows. Application 105 can issue a PUT (e.g., HTTP PUT) command to the queue manager 110 to put (or write) the message onto a queue (which is a particular storage location in memory). Application 125 can then issue a GET (e.g., HTTP GET) command to the queue manager 120 to get (or read) the message from the queue. In system 100, the applications 105 and 125 use the same name for the queue so that application 125 is able to reference and acquire the same message that was PUT into a queue by the application 105.
After the applications 105 and 125 have been developed, it may become desirable to insert extra processing into the architecture of system 100. For example, a customer might want to insert an additional application which collects statistical information about the messages as they are PUT to the queue. Additionally processing can be desired on either end of a message conveyance. That is an administrator of application 105 can desire processing occur relating to data of queue manager 110 in a manner transparent to an administrator of application 125. Similarly, an administrator of application 125 or queue 120 can wish to add an additional software routine in a fashion that is non-destructive to pre-existing communications with application 105.
Adding additional processing, however, results in referencing problems. That is, the application 105 that PUTs a message in a queue needs to reference the message and queue in the same matter and the application 125 with GETs the message. In other words, a conventional technique used to insert such extra processing into a queue stream is to “split” the existing queue into two. To illustrate, suppose the existing queue is called “A”. Splitting the queue involves defining two new queues, called “A1” and “A2”. The application 105 needs to modify code so that instead of PUTting messages to Queue A, the application 105 instead PUTs to Queue A1. Similarly, application 125 must be modified so that commands that originally GET a message from Queue A are changed to GET the message from Queue A2 instead. The extra processing (for example, collecting statistics) is implemented between Queue A1 and Queue A2. That is, the additional processing gets a message from Queue A1, executes necessary code associated with the processing, and places the processed message in Queue A2. This conventional technique permits code executing between Queue A1 and Queue A2 to be modified as necessary over time in a non-interfering manner.
An obvious disadvantage of this technique is that code of both the original applications 105 and 125 must be modified to reference Queue A1 and Queue A2, instead of referencing Queue A. Deployment of the modified applications 105 and 125 can be disruptive and expensive. Further, it requires a whole-scale change to be made to each queue utilizing application. Unmodified applications, will malfunction once the change has been implemented and modified applications will not function correctly until the change is implemented. Hence, the modified applications must be deployed simultaneously and comprehensively.
FIG. 2 (Prior Art) is a schematic diagram showing a system 200 that illustrates one pre-existing extension or modification to conventional queuing techniques. Specifically, system 100 permits queue aliasing. Queue aliasing permits a queue manager 220 to receive a message PUT to Queue A by application 205 through manager 210 and network 215. The received message is actually put to queue A1 225 instead of a non-existent Queue A, in accordance with the configurable mappings specified in alias table 230.
In a specific example of system 200, IBM's WebSphere Application Server has a platform messaging (PM) functionality which implements something called a “queue destination” which can support “mediations” (e.g., aliasing). This is achieved by allowing the queue destination to include separate “mediation points” and “queue points”. Specialized interfaces are provided for applications called “mediations”. These specialized interfaces can allow mediations to get messages from the mediation point (e.g., an original queue designator), and put them to the queue point (e.g., an alias). When conventional applications 205 put messages onto a queue destination (e.g., queue A), the messages are actually added to the mediation point (e.g., Queue A1) and when conventional applications 205 get messages from the queue destination (e.g., Queue A), the messages are actually got from the queue point (e.g., Queue A1).
Hence, in system 200, if we have an existing Queue A1 225, we can define an alias “A” in table 230 such that when an application 205 PUTs to Queue A, the queue managers 210, 220 can PUT the message on Queue A1 225. Use of conventional queue aliasing as shown in system 200 fails to result the problem of adding additional processing code without modifying pre-existing application 205 code. That is, aliasing of system 200 permits an application 205 to GET and PUT messages to a Queue A, when an actual queue for these messages is Queue A1. System 200 does not split the queue into two new queues so that additional processing can be performed between the split queues.
Appreciably, attempting to implement additional processing without splitting a queue can result in synchronization and interference problems. That is, a client can attempt to retrieve or GET a queued message before additional processing is performed or while additional processing is executing, both of which result in unpredictable processing behavior, which can cause computing errors.